Ask a controls engineer for the asset inventory and you’ll usually get one of two things: a spreadsheet last touched during a project closeout several years ago, or a confident “it’s in the historian somewhere.” Neither one survives contact with an auditor, and neither one is going to satisfy a regulator asking what was connected to a compromised HMI at 2 a.m. on the night of an incident. That gap between what plants think they know about their OT environment and what they can actually prove is about to become a much bigger problem.
CISA has been steadily raising the profile of OT asset visibility as a foundational control, not a nice-to-have, and the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) rulemaking is the mechanism forcing the issue. Once covered entities have defined reporting obligations for significant cyber incidents, you can’t report what a compromised asset was, what it talked to, or what it controlled if you don’t already know it exists. Asset inventory stops being a security-team wish list item and becomes a compliance prerequisite, the same way a P&ID or a lockout/tagout procedure is a prerequisite for safety compliance.
Why passive discovery alone gives you a false sense of confidence
The current wave of OT visibility tools — the passive network monitoring platforms that sniff SPAN ports and mirror traffic to fingerprint devices — solved a real problem. You used to have to touch every device to inventory it, which on a live production line is a non-starter. Passive discovery changed that. It’s non-intrusive, it scales, and it’s genuinely good at building a picture of what’s talking on the Ethernet/IP, Modbus TCP, or Profinet segments of your network.
It is also, by construction, blind to anything that isn’t generating network traffic your sensor can see.
That blindness matters more in OT than most security teams appreciate. A huge share of the installed base in a typical plant is legacy serial gear — RS-232/RS-485 links, proprietary fieldbus segments, standalone PLCs talking to remote I/O over DH+ or ControlNet, drives and instruments that predate Ethernet entirely. None of that shows up on a SPAN port. Passive tools also miss devices sitting behind protocol gateways or media converters, anything on a network segment your sensor isn’t tapped into, and equipment that’s air-gapped or only connected intermittently during commissioning, maintenance, or firmware updates. A skid vendor’s PLC that gets plugged in twice a year for a service visit will not show up in ninety days of passive capture, no matter how good the tool is.
None of this is a knock on the tools. It’s a knock on treating passive discovery as the finish line instead of the first pass. An inventory built purely from network traffic will confidently tell you about the twenty assets that are chatty and completely omit the eight that matter most because they’re old, isolated, or safety-critical enough that nobody wants to touch their network configuration.
The reconciliation problem nobody budgets for
Say your passive tool comes back with a clean list of a few hundred discovered devices. Now compare that against your CMMS asset register and your engineering drawings — P&IDs, network topology diagrams, control panel schedules. In most plants, those three sources disagree with each other in ways that are individually explainable and collectively alarming: the CMMS has assets that were decommissioned but never removed from the maintenance system; the drawings show a network architecture that was true at commissioning but not after three years of “temporary” changes; and the passive tool has found devices with IP addresses nobody in engineering or maintenance recognizes at all.
That third category is the one worth losing sleep over. An unrecognized device on the OT network is either an undocumented legitimate asset — a contractor’s laptop left plugged in, a vendor’s diagnostic gateway nobody logged — or it’s something worse. You don’t know which until someone walks the panel and looks.
Reconciliation is tedious, unglamorous work, and it’s exactly the step most OT security programs skip because the discovery tool’s dashboard already looks like progress. It’s also the step that turns a device list into an inventory anyone would trust in front of an auditor.
A phased approach that actually gets you there
Phase 1: Passive baseline
Deploy passive monitoring across your OT network segments to build the initial device list with minimal disruption. Treat this as a draft, not a deliverable. Its real value is in flagging communication patterns and protocol traffic you didn’t know existed — which is often the first sign of undocumented connectivity between IT and OT that will matter enormously for incident scoping later.
Phase 2: Engineering walk-down
Send someone with a controls background — not a cybersecurity analyst who’s never opened a panel door — through every control cabinet, junction box, and skid on the floor line by line. This is how you catch the serial-connected drives, the standalone safety PLCs, the remote I/O racks, and the vendor equipment that passive tools can’t see. Cross-reference against the passive tool’s output as you go: confirm what it found, add what it missed, and flag anything discovered on the network that the walk-down can’t physically account for. That last category is your priority-one investigation list.
Phase 3: CMMS and drawing reconciliation
Merge the walk-down and passive results into a single asset record, then reconcile against your CMMS and as-built drawings. Update the drawings — genuinely update them, with revision control, not a sticky note — and correct the CMMS asset register to match physical reality. This is also the point where you assign each asset the metadata that actually matters for CIRCIA-style reporting: what it controls, what safety or production function depends on it, what network segment it sits on, and who owns it.
Phase 4: The change-control hook
An inventory built once and never maintained is a historical document within a year. The only way to keep it current is to tie asset changes to your existing management-of-change process, so that any new device, firmware update, or network reconfiguration triggers an inventory update as a condition of closing out the work order — not an afterthought someone gets to eventually. If your MOC process doesn’t currently touch OT assets, that’s the gap to close before you invest further in tooling.
What this means for your next twelve months
Regulatory certainty around CIRCIA reporting timelines and thresholds is still taking shape, and exactly which entities are covered and on what schedule remains a moving target. That’s not a reason to wait. An inventory that reconciles passive discovery, physical walk-downs, and your CMMS is worth building regardless of which final rule lands, because it’s the same artifact you need for incident response, for spare-parts planning, for cybersecurity insurance underwriting, and for every IEC 62443 zone-and-conduit exercise your plant will eventually be asked to do anyway.
The plants that treat this as a compliance checkbox to satisfy the moment a rule takes effect will end up with exactly what they have now: a spreadsheet, just a newer one. The plants that treat it as a living system — passive tooling for continuous visibility, engineering walk-downs for ground truth, and a change-control hook to keep it honest — will be the ones who can actually answer the question when someone official finally asks it.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
